The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Virtual private network (VPN) technology is now widely used to provide secure communication of information over public or non-trusted networks. In a typical VPN arrangement, an end user is associated with an end station device, such as a workstation or personal computer, which executes VPN client software. The end station establishes a connection through a non-trusted network, such as the public Internet, to a gateway or other network node associated with a secure network of a business enterprise or other entity. The end station and network node negotiate encryption keys, essentially creating an encrypted “tunnel” connection through the un-trusted network. The end station and network node then communicate encrypted information over the un-trusted network, and the encrypted information is decrypted at the endpoints.
In this arrangement, the end user can securely obtain information from private network resources through the VPN tunnel, even though one or more intermediate networks are un-trusted. Typical VPN users are enterprise workers who telecommute or telework.
Such users of VPNs may wish to participate in other kinds of network communications, such as broadcasts of audio or video information. For example, assume that a business enterprise has numerous VPN users at locations remote from the headquarters of the enterprise. The enterprise may wish to establish a live broadcast event that uses Internet Protocol television (IPTV) protocol. An example of such an event might be a company meeting that all enterprise employees can view.
Some of the VPN users may receive the broadcast through unicast, such that the IPTV data is encrypted using the VPN tunnel associated with the VPN user. To support this operation, for each VPN telecommuter, a separate private encrypted session exists at a VPN processing device associated with the enterprise. However, this arrangement does not scale well for large broadcasts. For example, if 1,000 VPN telecommuters are online for a given broadcast, the VPN device at the enterprise must encrypt the broadcast event in 1,000 different encryption streams. This places a significant computing burden on the VPN device.
Further, communicating broadcast media information using a VPN tunnel may significantly reduce the amount of bandwidth available to the VPN end user for other communications. Such end users may need to perform other kinds of communication such as email, telnet sessions or HTTP browsing using information that is specific to a particular end user. Because broadcast media typically have high bandwidth requirements, communicating such broadcasts on a large number of VPN sessions may exceed the maximum available encryption throughput of the VPN device. As a result, end users may be unable to communicate the user-specific information when a broadcast is in process.
To illustrate these issues, FIG. 1 is a block diagram of a VPN arrangement in which a broadcast is communicated to multiple receivers. Within a trusted network domain 100, a broadcast server 102 generates a flow of broadcast packets that are directed to one or more receivers. Broadcast server 102 is communicatively coupled to the receivers through a local area network 104, VPN concentrator 106, and network 108. In one embodiment, the receivers comprise VPN clients 114A, 114B, 114C which are located in a non-trusted domain 110. Each receiver is associated with a network end station device. For example, VPN client 114A is associated with a workstation 116A, VPN client 114B is associated with a personal computer 116B, and VPN client 114C is associated with server 116C.
In this arrangement, the receivers can securely obtain resources from LAN 104 by establishing encrypted VPN links 112A, 112B, 112C that terminate at VPN concentrator 106. For example, a telecommuter using workstation 116A could retrieve email from a server located in LAN 104 using encrypted communications over link 112A. The receivers may also wish to participate in a broadcast that originates at broadcast server 102. However, to do so in the arrangement of FIG. 1, link 112A must carry the encrypted broadcast along with private encrypted traffic directed to workstation 116A. Moreover, VPN concentrator 106 must encrypt the same broadcast traffic repeatedly for each end user, using different encryption keys that are individually negotiated with each of the VPN clients 114A, 114B, 114C.
Since the broadcast data is the same for all end users who are receiving it, and since the broadcast data requires a high proportion of the download bandwidth to the user, benefits would accrue from an approach in which the broadcast data is encrypted into a single encryption session.
Thus, there is a need for a method or apparatus that can separate user-specific encrypted data traffic from encrypted broadcast traffic that is common to a group of users.